<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Build">
   <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
   <title>Eclipse Remote Development</title>
</head>
<body>

<h1>
Eclipse Remote Development<br>
Guidelines (Draft)</h1>
<i><font size=-1>Last revised 16:30 Monday April 2, 2002</font></i>
<p>The Eclipse Platform was designed to support a development model where both
the relevant files (e.g., Java source code) and the required tools (e.g., Java
compiler) reside on the developer's workstation. Call this is a <i>local
development paradigm</i>. The Java development tooling (JDT) is the prime example
of local development for Java programs. There are many environments where the
primary tools reside only on a remote system distinct from the developer's
workstation and, naturally enough, operate only on files that are directly
available to that remote system. One concrete example of this is developing
COBOL and RPG programs for IBM iSeries computers. Other examples include
developing for mainframes or servers with legacy tools that do not exist in a
compatible form outside that environment. A simple local development model is clearly
inappropriate for these environments. One instead wants a <i>remote development
paradigm</i>  that factors in the fact that the user is dealing with tools and files on a
system remote from the developer's workstation.</p>
<p>This document explains how the Eclipse Platform can also be extended by
plug-ins to support a remote development paradigm, and provides recommendations and
guidelines for plug-in developers building remote development support.</p>
<p>Table of contents:</p>
<blockquote>
  <ul>
    <li><a href="#Eclipse Platform and local development">Eclipse Platform and local development</a></li>
    <li><a href="#Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></li>
    <li><a href="#Different modes of remote development">Different modes of remote development</a>
      <ul>
        <li><a href="#Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a>
          <ul>
            <li><a href="#Shared access to workstation-resident file base">Shared
              access to workstation-resident file base</a></li>
            <li><a href="#Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></li>
            <li><a href="#Recommendations 1">Recommendations</a></li>
          </ul>
        </li>
        <li><a href="#Eclipse remote development with remote system-resident file base">Eclipse remote development with
          remote system-resident file base</a>
          <ul>
            <li><a href="#Shared access to remote system-resident file base">Shared
              access to remote system-resident file base</a></li>
            <li><a href="#Replicate remote system-resident file base to workstation">Replicate
              remote system-resident file base to workstation system</a></li>
            <li><a href="#Recommendations 2">Recommendations</a></li>
          </ul>
        </li>
      </ul>
    </li>
    <li><a href="#Conclusion">Conclusion</a></li>
    <li><a href="#Appendix: Eclipse Remote Development Example">Appendix:
      Eclipse Remote Development Example</a>
      <ul>
        <li><a href="#Variation 1 - Remote system-resident file base">Variation
          1 - Remote system-resident file base</a></li>
        <li><a href="#Variation 2 - Workstation-resident file base">Variation 2
          - Workstation-resident file base</a></li>
      </ul>
    </li>
  </ul>
</blockquote>
<h2><a name="Eclipse Platform and local development">Eclipse Platform and local development</a></h2>
<p>This section reviews the Eclipse Platform's approach to local development.
Many aspects are explained in more detail in the <a href="http://www.eclipse.org/whitepapers/eclipse-overview.pdf">Eclipse
Platform Technical Overview (http://www.eclipse.org/whitepapers/eclipse-overview.pdf)</a>,
which provides a high-level overview of the entire Eclipse Platform.</p>
<p>The Eclipse <i>workbench</i> provides the UI personality of the Eclipse
Platform, and supplies the structures in which tools interact with the user. The
Eclipse Platform UI paradigm is based on editors, views, and perspectives:
editors allow the user to open, edit, and save objects; views provide
information about some object that the user is working with in the workbench;
perspectives control the initial view visibility, layout, and action visibility
for editors and views visible on the screen in the workbench window. Tools integrate into
the editors-views-perspectives UI paradigm by extending the workbench with new types of
editors, views, and perspectives, or by augmenting existing ones.<o:p></o:p>
 This is done via several workbench extension points. Eclipse provides a handful
of standard views, editors, and perspectives, all contributed via these
extension points.</p>
<p>The Eclipse <i>workspace</i>
consists of one or more top-level projects,
where each project maps to a corresponding user-specified directory in the local
file
system. The different projects in a workspace map to different file system
directories, possibly on different drives. A project contains files that are created and manipulated by the
user; these files are directly accessible to the standard programs and
tools of the underlying operating system, as well as to tools more tightly
integrated with the Eclipse Platform. The Platform models projects, files, and
folders (collectively termed resources) in the workspace and provides an API for
operating on workspace resources. A workspace resource tree is maintained in
memory at all times, allowing hierarchy navigation to be uniformly fast and
independent of the speed of the underlying local file system. Resource change
listeners give tools a reliable way to track changes
to workspace resources by using after-the-fact notifications of all resource creations,
deletions, and changes to the content of files. Event
reports take the form of a tree of resource deltas describing the effect of the entire batch of operations in terms
of net resource creations, deletions, and changes. Workspace resources can be
annotated with markers and properties, and are adaptable so that other parties can extend their
behavior.
</p>
<p>Although the workbench and workspace are typically used in conjunction, the
central mechanisms for editors, views, and perspectives are independent of
workspaces and resources. The primary workbench dependence on workspaces and resources is
found in some of the standard views (notably the Navigator view and Tasks view)
and in the standard text editors (which expect as input a file in the
workspace).
</p>
<p>To support a local development paradigm in Eclipse, <o:p></o:p>a tool
integrates with both the Eclipse workbench and the Eclipse workspace. The code
for the tool runs on the workstation in the same process as the Eclipse
Platform, contributes UI elements to the workbench, and operates on files found
in projects in the workspace. This arrangement is called into question when we
consider a remote development paradigm: the tools to be integrated do not exist
on the workstation running Eclipse, and the files on which these remote tools
operate are on the remote system rather than not on the workstation.
</p>
<p>For remote development, good integration with the Eclipse workbench is
crucial (and as crucial as it is for local development) because it affects the
overall user experience when running the Eclipse IDE. In principle, this is
achievable with a tailor-made Eclipse Platform plug-in that (a) fronts for, and
communicates with, tools running on the remote system, and (b) quietly
orchestrates the behind-the-scenes shuffling of important data and files between
the workstation and remote system.&nbsp;
</p>
<p>The key observation is that the
plug-in that controls the UI and implements the underlying object model has <i>carte
blanche</i>, and can make the user believe most anything it wants the user to
think. In particular, it can present the user with objects that correspond to
files on the remote system, and can do so regardless of whether the file is
actually available as a local file in the workspace. As long as the user
feels that the Eclipse IDE provides them with what they need to get their job
done, there is considerable flexibility regarding when and how source files are
materialized as resources in the Eclipse workspace.
</p>
<p>The main goal for any IDE is to provide for the developers'
needs by giving them a familiar setting in which to develop kinds
of programs (or web content, or whatever they are developing). In the Eclipse
context, a second goal is to provide this support in a modular way via a plug-in
(or family of related plug-ins) in a way that
fits with the Eclipse workbench and with other installed plug-ins, allowing users
to transition smoothly between heterogeneous tasks being done within the same
IDE. Both of these overarching goals apply regardless of whether the files and tools
are on the workstation or on a remote system. So in an important sense, the
overall game is the same in all cases.</p>
<p>Before delving in to how remote development can be made to work in Eclipse,
it is useful to review how the standard Eclipse workbench and workspace
facilities are used in practice. The following general guidelines outline recommended ways to support a
local development paradigm with the Eclipse Platform:</p>
<blockquote>
  <ol>
    <li> Use projects for coherent, long-lived development
activities of a distinctive sort.</li>
    <li> Use a distinctive project capability (project nature) to mark the
project.</li>
    <li>Define an object model for the entities of interest to the user.</li>
    <li>Use suitable views to present the object model to the user.</li>
    <li>Use actions to allow the user to manipulate the objects.</li>
    <li>Use a perspective to arrange high-interest views and editors
      to the user.</li>
    <li>Use suitable editors for editing objects.</li>
  </ol>
</blockquote>
<p> Java development tooling (JDT) is used as the example to illustrate how these
guidelines are applied.</p>
<p><b>1. Use projects for coherent, long-lived development
activities of a distinctive sort.</b></p>
<p>Projects in the Eclipse workspace are used to collect together the objects
and files created and modified in the course of a long-lived development
activity. Projects are also the standard unit for version and configuration
management (VCM) and team support. The workbench gives the user general actions for creating, opening,
closing, deleting, copying, and renaming projects. A single workspace may
contain any number of projects. Using a project for any big ticket activity,
even if it's just a shell of a project without any files or folders, affords
the user a way to multi-task by switching between projects at their discretion. It is undesirable (and unnecessary) to presume that there would only be one project
in a workspace. A multiplicity of projects is the norm.</p>
<p>For example, if the user is to develop a new payroll applet in Java, they can be expected to create themselves a new project
(named &quot;Payroll&quot;) for this activity.</p>
<p><b>2. Use a distinctive project capability (project nature) to mark the
project.</b></p>
<p>Projects in the Eclipse workspace are endowed with sets of project
capabilities (new 2.0 mechanism) that determine in part how the project is
presented to the user. Internally, project capabilities are implemented in terms
of project natures (1.0 core mechanism). Giving a project a distinctive capability
allows the project's presentation to be tailored appropriately. It is undesirable (and unnecessary) to presume that all projects in the
workspace have comparable capabilities. Heterogeneity is the norm. It is also
desirable to allow a single project to be configured with multiple capabilities;
this makes it possible for a single project to support several related
development activities.</p>
<p>The user's &quot;Payroll&quot; project has the capability for developing Java
programs (capabilities are usually acquired at
project creation time, but can also be added or removed from any existing
project). Internally, the project is tagged with a
distinctive Java project nature. The Java capability can be used in conjunction
with other capabilities (PDE is just one example).</p>
<p><b>3.&nbsp;Maintain an object model for the entities of interest to the user.</b></p>
<p>The object model is the Eclipse-side division of the relevant chunk of the
world into objects. There is considerable flexibility in how an object model is
built and maintained. Some objects might correspond directly to files
(somewhere), while other might be synthesized from information gathered from
multiple disparate sources.</p>
<p>The JDT object model is known as the Java model. It models Java-specific
objects called Java elements, including: Java projects, Java source files; type,
method, and field declarations; packages directories; and JAR libraries. Each
Java project has a single special classpath file (named &quot;.classpath&quot;
and stored in the project's root directory of the project) that records
Java-specific information about the project. This information includes the
locations of the project's source folder(s), pre-compiled JAR libraries, and the
output folder for compiler-generated binary class files. Java source files, and
the generated binary class files, are stored as file resources in
package-name-based folders under the Java project. JAR libraries, on the other
hand, may be file resources in the workspace or files in the local file system
beyond the workspace.</p>
<p>Thus the Java model is generated from information lying both inside and outside the
workspace. Essential information is generally kept in internal in-memory data structures to ensure that
important object model
navigations can be performed instantaneously; navigations which involve
significant computation (e.g., opening source files and JARs, creating type
hierarchies) are supported by API designed to allow internal caching but not
force pre-computation or arbitrary retention of expensive structures. The Java
model provides Java element deltas in the same spirit as workspace resource
deltas, and uses resource markers to record compiler-detected problems against offending Java
source files.&nbsp;</p>
<p>Thus the Java model is designed to support the needs of the JDT UI and of
client tools that present and manipulate Java code. And although much of the raw
content of a Java project comes for files stored in that project, the
relationship between the files resources in a Java project and Java model
objects is far from a simple correspondence: some Java model objects correspond
directly to workspace resources (e.g., Java project and source files); some
files in the workspace project have no corresponding Java model objects (e.g.,
the generated class files); and some Java model objects do not correspond to
workspace resources at all (e.g., declarations, and external JAR libraries).</p>
<p><b>4. Use suitable views to present the object model to the user.</b></p>
<p>The workbench UI window holds an arrangement of views and editors. Views
present a selection of objects in the object model to the user and provide the
main &quot;handles&quot; by which the user manipulates or otherwise interacts
with model objects.</p>
<p>The JDT Packages view is a navigator-like tree listing all (and only) Java projects in the
workspace, with a tree of Java elements objects shown under each project. (This view presents a mix of objects from the workspace model
(projects, source files) together with Java element objects.) The Eclipse JFace viewer framework makes it easy to define
a content provider which feeds object model elements to the viewer,
and a label provider to control the visual appearance (label and icon) of the
items.</p>
<p><b>5. Use object actions to allow the user to manipulate the objects.</b></p>
<p>Objects shown in a view have associated actions which the user can see and
select from the view's context menu.</p>
<p>For example, Java elements like methods provide &quot;delete&quot; and
&quot;rename&quot; actions with Java-specific meanings. The &quot;open&quot; action on these
element opens a Java editor of the appropriate Java source file and scrolls the
window to show the text of the method declaration.</p>
<p>JDT also adapts the Eclipse launch framework to launch Java programs, and the
Eclipse debugger framework to provide a
debugger for Java programs.</p>
<p><b>6. Use a perspective to arrange high-interest views and
editors to the user.</b></p>
<p>The initial choice and arrangement of views and editors in a workbench UI
window is given by a workbench perspective. Perspectives help to reduce clutter
and keep the user's attention focused on the task at hand.</p>
<p>JDT provides a pre-defined Java perspective suited to Java development. It includes the
Java Packages view, the standard workbench Tasks view, and an editor area.</p>
<p><b>7. Use suitable editors for editing objects.</b></p>
<p>Certain model objects have contents that the user can view and edit with a
suitable editor, be it textual or graphical. Editors are most typically launched
by a &quot;open&quot; action on objects shown in a view. The object's editable
contents is read in to memory when the editor is launched; changes are written
back when the user issues a &quot;save&quot; or &quot;save as&quot; command.</p>
<p>The &quot;open&quot; action for a Java source file object opens a standard
Eclipse text editor that has been specialized for editing Java source code.
Standard text editors
reading the contents of
the file from the workspace, and the editor
&quot;save&quot; action writes the modified buffer contents back to the file (or creates a new file in
the case of &quot;save as&quot;).</p>
<h2> <a name="Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></h2>
<p>With respect to supporting a remote development paradigm in Eclipse, the JDT
example illustrates the following key ideas:</p>
<ul>
  <li>Eclipse workspace integration is achieved chiefly through using projects,
    project capabilities, and file resources within the project.</li>
  <li>Eclipse workbench integration is achieved through suitable perspective,
    views, editors, and actions.</li>
  <li>The object model completely determines the objects the user gets to see
    and manipulate.</li>
</ul>
<p>The general approach for using Eclipse to develop programs on a remote system
is obvious enough:
</p>
<ul>
  <li>Define a suitable
    project capability for remote development of the desired sort.</li>
  <li>Build a suitable object model including objects that correspond to things
    on the remote system. The canonical remote object is a file on the remote
    system.</li>
  <li>Build a suitable perspective,
    views, editors, and actions to show this object model to the user.</li>
  <li>Actions, such as ones on remote objects, communicate with tools running on the remote
    system.</li>
  <li>Editors opened on remote file objects access the contents of the file from
    the remote system, and stores the changed contents back sometime after
    editing is done.</li>
</ul>
<p>The interesting design question is how best to arrange for a source file to be
available for editing on the workstation and also be available to the compiler
running on the remote system.</p>
<p>This turns out to be the crux of the matter, and key to understanding what
role workspace resources can play and where a team repository could fit in this
remote development picture.</p>
<h2><a name="Different modes of remote development">Different modes of remote development</a></h2>
<p>Up to this point we have been ignoring a very crucial question: Where do source files come
from, and where do the changed source files need to end up? Although the simple &quot;Hello World&quot; example program gives the
impression that all programs enter the development picture from the programmer's
finger tips, this is hardly representative of what goes on in real life. In practice, source
code is part and parcel of a file base that grows and evolves over a long period
of time through the efforts of a team of developers. Before a developer can do
any work, they must acquire a replica of the file base to work on. And when they are all through, the
modified file base containing the source files that were changed must be put
somewhere safe; otherwise, the changes would be lost, making the whole exercise
pointless.</p>
<p>If a developer is planning to do remote development, it is fair
to ask where the file base containing the source files enters and exits the
picture. There are two possibilities: the workstation or the remote system. Both
may be valid ways of working in certain environments; both are different from
each other; both can be supported.</p>
<blockquote>
<p><b>Workstation-resident file
base</b>&nbsp;<b> </b>The source files enter and exit the picture at the workstation,
exactly as they do in local development. Two common ways that this happens are (1) the developer accesses a team repository from their
workstation, and (2) the developer unzips a source release into the workstation's
local file system to be worked on there. Call this arrangement a <i>workstation-resident file
base</i>. Since the files are available on the workstation, there is no real
problem with editing them on the workstation. In this arrangement, the problem
is making the files on the workstation available to tools that run on the remote
system.&nbsp;</p>
<p><b>Remote
system-resident file base</b>&nbsp; The source files enter the picture at the remote system. Three common
ways that this happens are (1) the developer accesses a file base from a pre-existing library
on the remote system, (2) the developer accesses a team repository directly from the
remote system, and (3) the developer unzips a source release into the remote
system's local file system to be worked on there. Call this arrangement a <i>remote
system-resident file base</i>. Since the files are available on the remote
system, there is no real problem with accessing them from tools running on the
remote system. In this arrangement, the problem is making the files on the
remote system available to editors that run on the workstation.</p>
</blockquote>
<p>While workstation-resident file base and remote system-resident file base
are similar in many respects, they are fundamentally different in important ways.
Each has its own distinct problems and non-problems. Each has a solution
involving similar mechanisms, although the mechanisms get used in subtly different ways.
We consider each mode in turn, starting with the one that is closest to local
development.</p>
<h3><a name="Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a></h3>
<p>With a workstation-resident file base, the workstation has a replica of the file
base that is complete and accurate at all times. Any editing that happens
affects this file base directly.</p>
<p>As with a local development paradigm, the recommended location for this file
base replica is inside the developer's Eclipse workspace, in the project content
area of some project. In other words, the source files in the file base are
stored as file resources under a suitable project in the Eclipse workspace. The
user can use any general purpose Eclipse team provider, such as CVS, to provide
team support and version and configuration management for the project's important files.</p>
<p>There are two general approaches to making the file base on the workstation
available to tools running on the remote system: shared access and replication.</p>
<h4><b><a name="Shared access to workstation-resident file base">Shared access to workstation-resident file base</a></b></h4>
<p>The shared access approach involves locating the content area for the project
on a network file system drive that will be accessible to the
remote system as well as to the workstation. The actual files might be stored on
the workstation's local disk, on the remote system's local disk, or on the disk
of a network file server. No matter. As long as both systems can access them.</p>
<p>The advantage of this arrangement is simplicity: there are no replicas of the
file base to get out of sync. Change made by editing the source file on the
workstation are immediately visible to tools on the remote system.&nbsp;</p>
<p>This arrangement supports offline editing in some circumstances. If the
remote system becomes temporarily unavailable to the workstation, the user can
continue editing as long as the file base is still available to the workstation.
However, if the file base is actually stored on the local disk of the remote
system, the user would be unable to do any work on that project while the remote
system is offline or is otherwise disconnected from the workstation.</p>
<p>This arrangement supports remote system retargeting: the user can switch an
existing project to a different remote system as long as it can see the file
base on the network file system drive.</p>
<h4><b><a name="Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></b></h4>
<p>The workstation starts off with the replica of the file
base that is complete and accurate; the remote system starts off without any
part of the file base.&nbsp;</p>
<p>This approach involves replicating the file base from the workstation to a
corresponding area on the remote system. Since an Eclipse workspace is a
developer's private sandbox, the corresponding area on the remote system should
also be a private developer's sandbox. Under these conditions, replication is
straightforward because it can always always be in one direction and there is no
need to detect or resolve conflicts. Initially, the replica on the remote system
is established by copying over the entire file base. Afterwards, it can be
updated incrementally to match changes that happen to the master file base on
the workstation. For instance, when the user edits a source file and saves the
changes to their workspace file resource, the replica on the remote system
becomes out of sync with the workstation. The changed file must be copied to the
remote system to update the replica there, thereby bringing it back into sync.
If resynchronization happens before a tool on the remote system accesses the
replica, the workstation and remote system replicas will appear to behave as a
seamless unit from the user's point of view. Eclipse Platform
core target management provides infrastructure for building file synchronizers which
can record and queue up batches of files that have been added, deleted, or changed.
If the remote system replica is corrupted or becomes untrustworthy, it can be
scrubbed and rebuilt from the workstation file base, which is always complete
and the completely up to date.</p>
<p>Figure 1 illustrates the general pattern of activity surrounding this kind of
replication.</p>
<p align="center"><img border="0" src="rd-wrfb.gif" width="647" height="300"><br>
<br>
Figure 1.Activity pattern in workstation-resident file base replicated to remote
system</p>
<p>The chief advantage of replicating over shared access is that this approach
can be used in all environments, including ones where there is no network file
system drive common to both systems. The chief expense of this arrangement is
the cost of initial replication; the incremental maintenance of the replica is a
lesser expense. Because the file base is actually copied from workstation to
remote system under control of the remote development plug-in, there is
maneuvering room to account for differences between the operating environments
of the workstation and the remote system: file names and paths could be
systematically remapped; and text file contents could be mapped to a code page
more appropriate for the remote system.</p>
<p>This arrangement also supports offline editing, and remote system retargeting
at the cost of replicating the file base to each new remote target system.</p>
<h4><a name="Recommendations 1">Recommendations</a></h4>
<p>The replicating approach is generally recommended for all operating
environments due to its flexibility, universal applicability, support for
offline editing, and the ability to retarget to different a remote system. This
approach is robust in the face of disconnections between the workstation and the
remote system because the workstation always has the complete and perfectly
up-to-date replica of the file base. As long as the workstation does not fail
catastrophically, the connection to the remote system (or indeed the entire
remote system) could be lost without the user losing important
work.</p>
<p>The shared access approach is recommended only in operating environments
where all of the following conditions are true: (a) the network file system
drive is accessible to the workstation and remote system at all times; (b) the
network file system drive is fast enough to support the respective needs of each
system; (c) file names and paths are identical on both systems; (d) the
character encoding for text files are the same for both systems; (e) there is no
problem with additional files created in the workstation project being visible
to tools on the remote system; and (f) there is no need to interoperate with a
team provider (or other plug-in) trying to play similar games by locating the
content area of a workspace project on a special network file system drive
(e.g., the Rational ClearCase team provider uses network file system drives for
its dynamic views in some operating
environments).</p>
<h3><a name="Eclipse remote development with remote system-resident file base">Eclipse remote development with remote system-resident file base</a></h3>
<p>With a remote system-resident file base, the problem that must be solved is
making the files on the
remote system available to editors that run on the workstation. Again, there are
two general approaches: shared access and replication. Shared access is the
same, but replication is different in some important respects.</p>
<h4><b><a name="Shared access to remote system-resident file base">Shared access to remote system-resident file base</a></b></h4>
<p>There is no difference between shared access to the remote system-resident
file base and shared access to the workstation-resident file base. The approach
has the same advantages and drawbacks as listed in the preceding section.</p>
<h4><b><a name="Replicate remote system-resident file base to workstation">Replicate remote system-resident file base to
workstation</a></b></h4>
<p>The remote system starts off with the replica of the file
base that is complete and accurate; the workstation starts off without any part
of the file base.&nbsp;</p>
<p>When the user opens an Eclipse editor on a remote file object, the contents
to the file can be retrieved from the remote system file base and loaded into
the editor's buffer. When the user saves the buffer, the modified contents can
be stored back from the remote system overwriting the original file. All this
can happen without the user having to be conscious of the fact that both systems
are heavily involved. (Some standard Eclipse text editors operate exclusively on
files in the workspace; the same is true for system editors which operate
directly on files in the local file system and completely bypass the Eclipse
workspace API. Using one of these editors requires the familiar dodge of
materializing a temporary file in the workspace, opening the editor, sending
back the changed contents when the temporary file is rewritten, and deleting the
temporary file when the editor closes.)&nbsp;</p>
<p>This simple scenario suggests that it is not absolutely necessary to
replicate <i>any</i> files in the remote system file based to the Eclipse
workspace on the workstation. An editor could work exclusively off a transient
copy of the remote file's content; the file never need materialize as a file
resource in the workspace project. Nevertheless, there are advantages to
replicating <i>some</i> of the files in the remote file base to the workspace
project.</p>
<p>This approach involves selectively replicating files from the file base on
the remote system to the workspace project. A file in the file base is
replicated from remote system to workstation on request. When the user edits a
source file and saves the changes to their workspace file resource, the replica
on the remote system becomes out of sync with the workstation. The changed file
must be copied back to the remote system to update the replica there, thereby
bringing it back into sync. If resynchronization happens before a tool on the
remote system accesses the replica, the workstation and remote system replicas
will appear to behave as a seamless unit from the user's point of view.</p>
<p>Maintaining a replica of selective files on the workstation improves
performance over a pure remote approach&nbsp; because frequently edited files
only have to be copied to the workstation once, as opposed to each time the
editor is opened. The workstation replica also allows some offline editing that
would be impossible in the pure remote approach.</p>
<p>Figure 2 illustrates the general pattern of activity surrounding this kind of
replication.</p>
<p align="center"><img border="0" src="rd-rsrfb.gif" width="627" height="300"><br>
<br>
Figure 2.Activity pattern in remote system-resident file base replicated to
workstation</p>
<p>While superficially similar to replication involving a workstation-resident
file base, the overall characteristics are quite different:</p>
<ul>
  <li>The workstation usually has only a partial replica of the file base. (This
    is different. With a workstation-resident file base, the workstation always
    has a complete replica.)</li>
  <li>Systematic remapping of file names and paths between the systems is
    possible. (Same, although the mapping must be fully bi-directional.)</li>
  <li>Code page conversion of text file contents between the systems is
    possible. (Same, although the mapping must be fully bi-directional.)</li>
  <li>Creating a replica on the workstation involves copying from remote system
    to workstation. (Different. Copying never happens in this direction with a workstation-resident file
    base.)</li>
  <li>Resynchronizing after a file has been edited involves copying from
    workstation to remote system; the updates can be deferred, batched up, and
    done incrementally. (Same.)</li>
  <li>If the replicas on the workstation and remote system are in sync, the
    remote system has a complete and up-to-date file base. (Same.)</li>
  <li>If the replicas on the workstation and remote system are out of sync,
    neither system has a complete and up-to-date file base. (Different. The
    workstation always has a complete and up-to-date replica.)</li>
  <li>If the file base on the workstation is corrupted, the user loses important
    work (unless the systems happen to be in sync). (Same.)</li>
  <li>If the file base on the remote system is corrupted, the user loses
    important work. (Different. With a workstation-resident file base, the
    remote system file base is expendable, and can be rebuilt by scrubbing and
    recopying the workstation's file base.)</li>
  <li>If the connection to the remote system is lost, only files already
    replicated to the workstation will be available for editing while offline.
    (Different. All files are available for editing at all times with a workstation-resident file
    base.)</li>
  <li>If the connection to the remote system is lost while the workstation and
    remote system are out of sync, changed files in the workspace will be
    stranded in the workspace awaiting the connection to the remote system to be reestablished. (Different.
    In a workstation-resident file base, the remote system is not
    involved in ensuring that the changed files make it to save haven.)</li>
  <li>The workspace project cannot be retargeted to a different remote system
    without losing the file base. (Different. Retargeting is easy with a workstation-resident file
    base because the
    remote system is expendable.)</li>
</ul>
<p>Due to the fact that the putative master copy of the file base is kept on the
remote system and not the workstation, general purpose Eclipse team providers
associated with the workspace cannot provide VCM and team support for the
project's important files. However, the remote system may have its own tools for version and configuration
managing files and for supporting teams of developers working together. If it
does, the obvious first approximation is to treat these tools much like other remote system
tools: the plug-in that supports remote
development should provides appropriate views and actions on remote
objects to invoke these tools.&nbsp;</p>
<p>Version 2.0 of the Eclipse Platform allows pluggable VCM and team support via team providers.
Projects in the workspace can be assigned a team provider; each workspace
project can have a different one. The recommended way to achieve good
integration with the Eclipse workbench is to build special-purpose team
providers for the various VCM and team products available on the remote system.
The user could then be given a choice of suitable remote team providers for their
remote projects.</p>
<h4><a name="Recommendations 2">Recommendations</a></h4>
<p>When the file base resides on the remote system, the replicating approach is
generally recommended for all operating environments due to its flexibility,
universal applicability, and support for limited offline editing. This approach
is somewhat robust in the face of disconnections between the workstation and the
remote system because the workstation always has the more up-to-date replicas of
any files it has on hand. However, as long as there are files that have been
changed in the workspace but not synchronized with the remote system, the user
will not be able to reach closure until the remote system comes back online and
their changes committed to the master copy of the file base.</p>
<p>The shared access approach is recommended only in operating environments
where all of the conditions listed in the earlier section are true.&nbsp;</p>
<h2><a name="Conclusion">Conclusion</a></h2>
<p>Workstation-resident file base and remote system-resident file base
characterize the two main operating environments for remote development. Remote
development with the Eclipse Platform can support either mode.</p>
<p>The operating environment that is important to the majority of customers will
likely dictate one approach over the other. For instance, there are extensive
libraries of COBOL and RPG code that have always resided on the IBM iSeries and
zSeries mainframe computers. This suggests treating them as having a remote
system-resident file base. Full integration with Eclipse would require writing
specialized team providers that work with existing VCM products native to these
systems (e.g., Alden for the iSeries).</p>
<p>On the other hand, there are a burgeoning number of hardware vendors making
their high-end Linux systems available to open source developers to encourage
porting and tuning of applications there (for example, the Open Source
Development Lab at <a href="http://www.osdlab.org">http://www.osdlab.org</a>).
In this case, the file base is not pre-existing on the remote system and full
offline editing is desirable, which suggests a workstation-resident file base is
appropriate. The open source developer loads the C/C++ code for their
application from the CVS open source repository into their Eclipse workspace;
the file base is then replicated to the remote system where it is compiled and
run.</p>
<p>Could a single remote development plug-in be built to support operating
environments with either a workstation-resident file base or a remote
system-resident file base? The answer is undoubtedly yes. Whether the extra work
to support both would be worthwhile depends on the mix of customers being
served.</p>
<h2><a name="Appendix: Eclipse Remote Development Example">Appendix: Eclipse
remote development example</a></h2>
<p>This appendix walk through a simple example of remote development with
Eclipse, just to show how the various elements come together in practice.</p>
<h3><a name="Variation 1 - Remote system-resident file base">Variation 1 - Remote system-resident file base</a></h3>
<p>As a hypothetical example of remote development, we consider how to let a
user develop FOOBOL programs on a legendary HAL
mainframe computer (of which there is only one remaining installation). Assume that
great library of existing of FOOBOL source files reside on local disk file
system of our HAL mainframe; assume that the developer's objective is to change some of
these library source files, and occasionally add new ones to the library; and,
finally, assume
that the FOOBOL compiler already exists for the HAL mainframe, but would be too
expensive to port to run on the workstation. Despite the example's crude
simplicity, it does have the essential elements common to
most remote development paradigms.</p>
<p>This example is a clear cut case of a remote system-resident file base.</p>
<p><b>1. Use projects for coherent, long-lived development
activities of a distinctive sort.</b></p>
<p>In our example, if the user is to develop a new payroll module in FOOBOL for
their HAL mainframe, they can be expected to create themselves a new project
(named &quot;Payroll&quot;) for this activity.</p>
<p><b>2. Use a distinctive project capability (project nature) to mark the
project.</b></p>
<p>The user's &quot;Payroll&quot; project has the capability for developing
FOOBOL programs for a remote HAL system (capabilities are usually acquired at
project creation time, but can also be added or removed from any existing
project). Internally, the project would be tagged with a
distinctive project nature.</p>
<p><b>3.&nbsp;Maintain an object model for the entities of interest to the user.</b></p>
<p>The FOOBOL user will be working with FOOBOL source code found in a library on
the HAL file system. So the object model would naturally contain objects
corresponding to FOOBOL source files. Internally, each file object would record
the coordinates (URL) of the actual file on the HAL file system; this
information is sufficient for identifying to both workstation and mainframe any
particular source file. If the library uses path-structured names, then the
object model would also contain objects corresponding to path prefixes
(folders).</p>
<p>The set of source files to be included in the object model might be as simple
as all files in a particular subtree of the HAL file system, or might be a list of
files in a variety of places hand-picked by the user. For simplicity, assume
that it's the former. All &quot;seed&quot; information that is obtained from the
user (the host name and port of the HAL computer, user id
and password for authentication, root source directory, etc.) is remembered on disk so that it is not lost when the workspace is shutdown..</p>
<p>Given the URL of the root directory, the names and URLs of all files in the
source tree are obtained in a single round-trip to the HAL mainframe. The
information returned is sufficient to generate the workstation object model. All
essential information is generally kept in in-memory data structures to ensure that object model
navigations can be performed instantaneously.</p>
<p><b>4. Use suitable views to present the object model to the user.</b></p>
<p>An appropriate main view for FOOBOL developer is a navigator-like view
listing all (and only) FOOBOL projects in the workspace. The tree of FOOBOL
source file objects are shown under each project. This view presents a mix of
project objects, from the workspace object model, together with remote FOOBOL
source file objects. The view is build with a standard JFace tree viewer and
specialized content and label provider.</p>
<p>When all objects that a user deals with are local, there is no value in
calling attention to that fact. Likewise when all objects are remote. With a
remote system-resident file base, any given FOOBOL source file object could be
in one of 3 interesting states: on HAL only; in workspace and in sync; in
workspace but out of sync. Which state a file is in may be quite important to
the user: files in the workspace will be still available if disconnected from
HAL, whereas others will not; out of sync files contain important changes that
have not been safely captured, whereas files that are in sync are expendable and
can be dropped from the local replica without loss of information. So while it is worthwhile to seamlessly integrate the remote with the local, it
does not pay to be too transparent about it. A specialized label provider
provides special icon decorations that manifest important background information
to the user.</p>
<p><b>5. Use object actions to allow the user to manipulate the objects.</b></p>
<p>FOOBOL source file objects have a &quot;compile in background&quot; action,
which launches the FOOBOL compiler on the HAL mainframe with the name of the
FOOBOL source file. The user continues to work while the compiler is running;
when the compile finishes, the collected error messages are retrieved and displayed to
the user
as a text log in a FOOBOL compiler messages view. Individual error messages are
also broken out and converted into markers. A special kind of problem marker is used to record the relevant source
file and offending line. If the remote file is not available locally, these
markers are placed instead on the &quot;Payroll&quot;
project resource. The &quot;open&quot; action on these markers retrieves
the contents of the appropriate FOOBOL source file from the HAL system and opens an
editor on it.</p>
<p>The Eclipse launch framework is adapted to launch FOOBOL programs to run on
the remote HAL system, and the debugger framework is used when writing a remote
debugger for FOOBOL programs running on the HAL system.</p>
<p><b>6. Use a perspective to arrange high-interest views and
editors to the user.</b></p>
<p>For working on the &quot;Payroll&quot; project, a pre-defined FOOBOL
perspective includes the FOOBOL project navigator view, the standard workbench
Tasks view, and an editor. The FOOBOL compiler messages view appears when needed
in the same place as the Tasks view.</p>
<p><b>7. Use suitable editors for editing objects.</b></p>
<p>The &quot;open&quot; action for a FOOBOL source file object opens a standard
Eclipse text editor that has been specialized for editing FOOBOL source code with
its fixed limit of 72 characters per line. The appropriate FOOBOL source file is
copied from the HAL mainframe to the workspace if it is not already held
locally. The user is informed whenever the
FOOBOL source file being opened for editing is being copied locally, so that
they can maintain a general background awareness of the whereabouts of their
files, in case the connection to HAL system suddenly drops. The contents of
the file is then read into memory by the editor; the editor
&quot;save&quot; action writes the modified contents back to the file. The
resource change callback signals that this file has changes which need to be
sent to the HAL
mainframe to replace the original source file contents. A specialized file synchronizer
is used to remember which files have been added, deleted, and changed. During the movement of text between
the HAL mainframe and the workstation, characters are converted between the
particular HAL character encoding and Unicode, which is used universally in the Eclipse Platform
and the Java 2 Platform.&nbsp;</p>
<h3><a name="Variation 2 - Workstation-resident file base">Variation 2 - Workstation-resident file base</a></h3>
<p>Let's change one assumption of the above example: assume that
great library of existing of FOOBOL source files reside in public CVS
repositories rather than on the local disk file
system of our HAL mainframe. We now have a clear cut case of a
workstation-resident file base. Consider how things change:&nbsp;</p>
<p><b>1. Use projects for coherent, long-lived development
activities of a distinctive sort.</b></p>
<p>No change.</p>
<p><b>2. Use a distinctive project capability (project nature) to mark the
project.</b></p>
<p>No change.</p>
<p><b>3.&nbsp;Maintain an object model for the entities of interest to the user.</b></p>
<p>No significant change. Even though the master copies of all HAL source files
are in the workspace, the object model still orients the user to developing on
the remote system.</p>
<p><b>4. Use suitable views to present the object model to the user.</b></p>
<p>No change.</p>
<p><b>5. Use object actions to allow the user to manipulate the objects.</b></p>
<p>No significant change. (Source files will always exist in the workspace to hang markers
on.)</p>
<p><b>6. Use a perspective to arrange high-interest views and
editors to the user.</b></p>
<p>No change.</p>
<p><b>7. Use suitable editors for editing objects.</b></p>
<p>No significant change. (There is never a need to copy a FOOBOL source file
from the HAL system to the workspace.)</p>
</body>
</html>
